<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<meta name="GENERATOR" content="TtH 3.67">
 <style type="text/css"> div.p { margin-top: 7pt;}</style>
 <style type="text/css"><!--
 td div.comp { margin-top: -0.6ex; margin-bottom: -1ex;}
 td div.comb { margin-top: -0.6ex; margin-bottom: -.6ex;}
 td div.hrcomp { line-height: 0.9; margin-top: -0.8ex; margin-bottom: -1ex;}
 td div.norm {line-height:normal;}
 span.roman {font-family: serif; font-style: normal; font-weight: normal;} 
 span.overacc2 {position: relative;  left: .8em; top: -1.2ex;}
 span.overacc1 {position: relative;  left: .6em; top: -1.2ex;} --></style>

                                                                                                                                                                                                                           
<title> Off-the-Record Instant Message \ for group conversation</title>
 
<h1 align="center">Off-the-Record Instant Message <br />for group conversation </h1>

<div class="p"><!----></div>

<h3 align="center">

,


 </h3>

<div class="p"><!----></div>


<div class="p"><!----></div>

<h2> Abstract</h2>
Instant messaging (IM) is becoming an integral part of social as well as business life. The main concern with IM is that the information is out in the open (unless the IM system is contained within a VPN). Off-the-record (OTR) protocol is designed to enable IM users to have private conversations . However, OTR protocol cannot currently support multi-user chatrooms via IM services and there is a need for a product that enables parties to meet in IM-based, virtual, and encrypted chatrooms. Such a product would be beneficial to especially small businesses. This paper shows how the OTR protocol can be extended to support multi-user conversations. The case study involves a proof of concept plugin developed for GAIM (an open source IM client that supports multiple protocols) and implementation details for the plugin.  

<div class="p"><!----></div>

<div class="p"><!----></div>


<div class="p"><!----></div>
 <h2><a name="tth_sEc1">
1</a>&nbsp;&nbsp;Introduction</h2>
Instant Messaging (IM) is the most popular message exchange system nowadays around the world. IM systems are becoming available even on cellular phones. More and more mobile devices support at least one IM technology these days and IM technologies are being utilized for business solutions. Given the status quo for the measures implemented for protection of users privacy or intellectual property, there is room for improvement for addressing issues such as confidentiality. 

<div class="p"><!----></div>
Users seem to prefer IM systems because they are not as intrusive as phone calls and not as uninteractive as e-mail. Some of the popular IM systems include Microsoft's MSN (or Windows) Messenger (MSN) [<a href="#re:msn" name="CITEre:msn">1</a>], American Online Instant Messaging (AIM) [<a href="#re:aim" name="CITEre:aim">2</a>], Google Talk, etc. and these systems are changing the way people communicate with friends, families and businesses partners. However, until recently, confidentiality support has been missing in the IM environment. Most IM protocols were implemented upon the public Internet, where there is no guarantee of secrecy of the transmitted IM messages. Even two users are sitting beside each other, the IM messages may still travel a path through routers and these messages are almost open to any eavesdroppers when there is no proper encryption and authentication. Moreover, besides eavesdropping, all the other potential vulnerabilities such as account hijacking, man-in-the-middle attacks, denial of service, etc. that exist in current distributed network applications apply to the IM systems. 

<div class="p"><!----></div>
As IM systems become part of the social and business infrastructure, concerns related to protecting the content of messages arise. The discussion of privacy in this paper will be kept limited to protecting the intellectual property of small businesses. The reason for focusing on small businesses is that a vast majority of them cannot afford buying the services that can ensure secrery of their intellectual property or confidentiality of their core competencies. 

<div class="p"><!----></div>
     <h3><a name="tth_sEc1.1">
1.1</a>&nbsp;&nbsp;IM system's architecture</h3>
One could probably consider  the Internet Relay Chat (IRC) as the first IM system. IRC provides a real-time communication service among a group of people regardless of their physical locations. In IRC, each participant needs to connect to a centralized IRC server and join a conversation channel (or topic). There are two types of conversations in IRC: one is public messages(i.e. which could be read by everyone in the same channel) and the other is private chat (i.e. messages exchanged between only two people, who may or may not be on the same channel) [<a href="#re:irc" name="CITEre:irc">3</a>]. Later on the true IM systems such as AIM, MSN, ICQ, Yahoo Messenger, and Google Talk etc. appeared. These systems share an identical concept and provide similar functionalities: real-time chat (peer to peer chat and chat room) and file transfer.

<div class="p"><!----></div>
Instant Messaging is a typical client-server distributed application and there exists two fundamental communication models:

<div class="p"><!----></div>

<ul>
<li> <b>Client-Server-Client:</b> All messages exchanged among participants need go through a server. No matter if the messages are system messages (i.e. the messages that are taken place between the client and the server to exchange status information, user's buddy list, buddy's IP address, buddy's status etc.) or the actual conversation payload.
<div class="p"><!----></div>
</li>

<li> <b>Peer-to-Peer:</b>  Only the system query and control messages are passed between the clients and the server. One party of the conversation could query the server to get the other party's IP address and use the IP address to establish another connection between them. <em>In this model, the server's only responsibility is to store all the clients information, which might be various from different IM systems but identically including information such as, user profiles, clients' IP addresses, client softwares' version, etc. And the servers should also provide a quering service in order to let the clients retrive these information. </em>


<div class="p"><!----></div>
</li>
</ul>

<div class="p"><!----></div>
     <h3><a name="tth_sEc1.2">
1.2</a>&nbsp;&nbsp;Potential Vulnerabilities</h3>
The message packages in public IM systems need to traverse through the public Internet regardless of the model and structure utilized. In general, these messages are not encrtypted and an eavesdroppers can stand on one router between two IM users, sniff their communication and read  their messages. Retreiving the contents of IM messages is a rather trivial task once one grabs the packets traversing in the network. Especially on a LAN network, all the packages are broadcasted in the local network and every one could hear all others messages. It becomes a little more inconvenient for an eavesdropper to sniff traffic if the LAN network is switch based but even then the eavesdropper could sniff the traffic from the line that connecst the switch to the router. There are other mechanisms available for sniffing traffic on a switched LAN however it's beyond the scope of our paper to discuss such attacks. The discussion about an evasdropper sniffing traffic is to justify the need for protecting the content of the IM messages via encryption. Nonetheless, the problem still remains as to how one would distribute the encryption keys as well as how the identity of a user can be verified.

<div class="p"><!----></div>
Account Hijacking is another popular attack in many IM systems. In such an attack, an attacker hijacks another user's IM account and impersonates that user in the conversations with others, mostly the hijacked account's buddy list. The reason for this attack is successful is most of the IM systems have vulnerable authentication mechanisms. Session identifier used by most of the IM protocals is not difficult to forge. An attacker could forge a similar legal key in accordance with the identifier's format. 

<div class="p"><!----></div>
Man-in-middle attack is another attack that is feasible in IM systems because of improper key exchange schemas. For instance, the Diffie-Hellman [<a href="#re:diffie-hellman" name="CITEre:diffie-hellman">4</a>] key agreement protocol, which is widely used by IM security products is vulnerable to such an attack. Suppose  Alice and Bob want to communicate privately and Alice initiates the Diffie-Hellman key exchange protocol. However, an eavesdropper, Carol, intercepts Alice's public key and sends her own public key to Bob. When Bob replies, Carol gets Bob's public key, substitutes it with hers and replies to Alice. Alice and Bob will think they are sharing a private secret with each other and all their messages encrypted by this secret are safe, but in fact, they are talking through a middle man, in this case Carol, who is reading the messages. Carol can go one step further and  modify the messages, re-encrypt with the appropriate key before delivering to the othe party. This vulnerability occurs because there is no authentication schema using in Diffie-Hellman key agreement protocol. One possible solution is to add fingerprints (or digital signatures) to each message.

<div class="p"><!----></div>
The above mentioned security issues in the IM environment are usually addressed by adding encryption and authentication (e.g. users authenticating one another). Nevertheless, only confidetiality and authentication are not enough to provide an off-the-record (OTR) conversation environment in which deniability property is also satisfied. In 2004's WPES, Borisov, N. et. al. proposed and implemented the OTR protocol [<a href="#re:borisov:04" name="CITEre:borisov:04">5</a>]. In a later version of the OTR protocol, a security flaw pointed out by Raimondo et al [<a href="#re:mario" name="CITEre:mario">6</a>] was fixed. OTR has two distinct security properties: perfect forward secrecy and deniability. Tese features will be discussed in the next section (Section <a href="#se:background">II</a>).

<div class="p"><!----></div>
This paper is composed of four sections and the remaining sections are organized as follows; Section <a href="#se:background">II</a> presents a introduction of current popluar mechanisms used for secure IMing; Section <a href="#se:otr">III</a> discusses the main concepts behind the OTR project and signifies the need for chatroom support, a feature missing in the OTR protocol; Section <a href="#se:methodology">IV</a> presents our implementation of secure group conversation based on the OTR protocol. Conclusion and future work are in Section <a href="#se:conclusion">V</a>.

<div class="p"><!----></div>
 <h2><a name="tth_sEc2">
2</a>&nbsp;&nbsp;Related Work</h2><a name="se:background">
</a>
Security in distributed applications is supported by a set of security services. International Organization for Standardization (ISO) defines five typical security services: access control, identification/authentication, confidentiality, integrity, and non-repudiation [<a href="#re:iso-security" name="CITEre:iso-security">7</a>]. However, for IM systems, some security features need to be reconsidered, especially, non-repudiation. In order to enable IM users to talk off-the-record,  deniability (repudiation) instead of non-repudiation is needed. In other words, a user should have the ability to deny what he or she said in the past. Several open source projects and some commercial software have addressed the security weaknesses existed in the current IM systems. Security in these applications is in general supported by encryption and authentication schemas.

<div class="p"><!----></div>
We will state a few of the IM clients that are in use today. Our focus is those that support or promise to support encryption. A complete survey of all the clients is beyond the scope of this paper. 
SimPro [<a href="#re:simpro" name="CITEre:simpro">8</a>] is a commercial software developed by Secway, a European company, providing privacy protection in IM systems. It includes:
	
<ul>
<li> Encryption of messages
<div class="p"><!----></div>
</li>

<li> Key infrastructure support for user authentication
<div class="p"><!----></div>
</li>

<li> Encrypted file transfers for MSN and ICQ/AIM
<div class="p"><!----></div>
</li>

<li> Secured recording of conversations
<div class="p"><!----></div>
</li>
</ul>
Moreover, encryption algorithm and authentication key agreement could be chosen by the users. The supported symmetrical algorithms for encrypting IMs are AES (128 bits), 3DES (Tripe DES, 128 bits), CAST (128 bits), Twofish (128 bits) and Serpent (128 bits). The asymmetrical algorithms supported by SimPro are used for authentication and key agreement and are RSA (2048 ou 4096 bits), Diffie-Hellman, ElGamal/DSA and Elliptic curves. SimpServer is a lightweight IM security gateway for Unix systems developed by the same company. All the network packages in the SimpServer system are be automatically encrypted.

<div class="p"><!----></div>
Google Talk: Google Talk system currently does not support IM encryption [<a href="#re:google-talk" name="CITEre:google-talk">9</a>]. Off-the-record property in Google Talk is that IM conversations will not be logged in the user's Gmail account. Google Talk is still in beta version and encrytion support is planned for the official release. 

<div class="p"><!----></div>
 MENTIONING TRILLIAN BRIEFLY...
Trillian is another IM client with multi-protocol support (like SimPro) [[[Reference to http://www.ceruleanstudios.com/learn/]]]. Trillian supports encrypted IM communication for AIM and ICQ protocols.  

<div class="p"><!----></div>
GAIM is an open source, multi-protocol IM client and it's available for Linux and WindowsTM operating systems [[[ref to http://gaim.sourceforge.net]]]. Adium X can be considered as GAIM's implementation for Apple's OS X since Adium uses libgaim for supporting IM protocols. 

<div class="p"><!----></div>
Gaim-Encryption is a security plug-in for GAIM and it uses NSS (Network Security Services) to provide transparent RSA encryption. It can automatically generate the public/private key pairs upon loading the plug-in. It also can automatically exchange the public keys during the initiation of conversations. Although Gaim-Encryption does not provide choice of encryption algorithms, it can be used as a wrapper and extended to support different encryption methods. Obviously, without authenticating the participants, it suffers the man-in-the-middle attack.

<div class="p"><!----></div>
Gaim-e is another encryption plug-in for GAIM. It uses GNUPG (GPG) to securely transfer the session key encrypted with RC5, a block cipher notable for its simplicity [<a href="#re:rc5" name="CITEre:rc5">10</a>]. Gaim-e plug-in currently works with AOL, MSN, and Yahoo (at the time of this writing, other protocols have not been tested yet) [<a href="#re:gaim-e" name="CITEre:gaim-e">11</a>].

<div class="p"><!----></div>
As the brief survey above shows, most of the available products for IM security address only part of the security services. Often, message integrity, perfect forward secrecy, and deniability are not addressed. The next product we will survey addresses these widely omitted concerns within the IM domain. 

<div class="p"><!----></div>
 <h2><a name="tth_sEc3">
3</a>&nbsp;&nbsp;Off-the-Record (OTR) Instant Messaging System</h2><a name="se:otr">
</a>
Borisov, N. et. al. proposed a comprehensive solution, the OTR protocol [<a href="#re:borisov:04" name="CITEre:borisov:04">5</a>], to address the weakness in current IM systems. Practically, they implemented a plug-in for the popular, open source, multi-protocol IM client, GAIM, and a local proxy which can be used by other IM clients. The OTR protocol is based on Deffie-Hellman key exchange agreement between the two parties who want to communiccate and all the applications are designed for only two parties. Under the OTR conversation environment, users can use most of the popular IM systems, such as MSN, AOL, and Yahoo, etc. and chat in a secure way. 

<div class="p"><!----></div>
     <h3><a name="tth_sEc3.1">
3.1</a>&nbsp;&nbsp;Basic concepts behind the OTR</h3>
The OTR protocol contains four basic cryptographic primitives: <br />
<b>Perfect forward secrecy</b> [<a href="#re:jablon96strong" name="CITEre:jablon96strong">12</a>] - Confidentiality (i.e. only the two communicating parties, Alice and Bob, should be able to read the conversation messages), is introduced by using short-lived encryption/decryption key(s). The basic idea is that the two parities, Alice and Bob, should forget used keys after they process the old messages (an old message is a message for which the encryption-transmission-decryption cycle is completed). And, it is computationally infeasible to generate used keys from the current key and long-term keys. The mechanism guarantees that even an eavesdropper is lucky enough to get the current key and compute the shared secret in use at the moment, it is still impossible to decrypt and read previous messages by using the compromised current key. OTR uses the well known Diffie-Hellman key agreement protocol [<a href="#re:diffie-hellman" name="CITEre:diffie-hellman">4</a>]  to provide perfect forward secrecy. Each key is used to secure one message only and a new key is used for transmitting the next message securely. <br />

<div class="p"><!----></div>
<b>Digital signatures and non-repudiation</b> - Digital signatures are used to authenticating users to make up for lack of authentication in Diffie-Hellman key agreement protocol. It is a popular approach in authentication protocols to use digital signatures that act as long-lived keys. These log-lived keys are solely for authentication purposes and are not used to encrypting IM messages in the OTR protocol. However, the signature along with the message leads to another problem. It enforces the non-repudiation property that the signatures can be verified by a third party without the cooperation of the owners and this property conflicts the deniability service required by an OTR IM session. The solutionto this problem is to  use Message Authentication Code (MAC) to authenticate IMs instead of the user's digital signature. In other words, the digital signatures authenticate the keys instead of the IMs and authentication of keys provides the identification service because only the person who has the right key can read the cipher texts. In the implementation, the previous key is used to authenticate the new key at every key refreshing stage. <br />

<div class="p"><!----></div>
<b>Message Authentication Code (MAC) and deniability</b> - Deniability is the ability to deny the content of conversations and it is addressed in the OTR protocol by using MACs. The generation of MACs is to use a one-way cryptographic hash function with a secret MAC key shared by conversation members. Alice uses her copy of the MAC key to compute a MAC of her message, and sends this MAC along with her message in a secure transmission channel; Bob verifies the integrity and authenticity of the message by computing the MAC for the received message using his copy of the shared MAC key and comparing with the MAC sent by Alice[<a href="#re:borisov:04" name="CITEre:borisov:04">5</a>]. Deniability is provided by using MACs for IMs: Carol, a third party, cannot prove that the message is sent by Alice, since she does not know the MAC key shared between Alice and Bob; and even Bob can not prove to a third party that the message really came from Alice, because both of them know the MAC key, and the message could have been forged by Bob. <br />

<div class="p"><!----></div>
<b>Malleable encryption and forgeability</b> - Forgeability, a stronger property than repudiation is provided by the OTR. Once the keys used to encrypt messages expire, the associated MAC keys for message authentication are revealed. The reason for revealing old MAC keys is to allow forgeability of messages for which their encryption keys have expired. This feature enhances the ability of Alice to deny that the messages are sent by her, because anyone could calculate MAC values on a modified message (even though it's encrypted) and validate it with one of the revealed MAC keys. OTR protocol uses a malleable encryption scheme (i.e. any change made to a cypher text will cause a meaningful change in the right position of the plaintext). Revealing of MAC keys together with malleable encryption scheme give a third party the ability to forge the messages sent by Alice and hence give Alice the ability to deny sending those messages. Moreover, anyone who recovers the MAC key in the future is unable to verify the authenticity of the messages sent in the past, which means even somebody can read the messages but  cannot prove who wrote the messages. <br />

<div class="p"><!----></div>
----- THIS SUBSECTION NEEDS TO BE CHECKED, EXPLAINED, and REWRITTEN-----

     <h3><a name="tth_sEc3.2">
3.2</a>&nbsp;&nbsp;Security Weakness in OTR</h3>  	
Mario Di Raimondo 	et al.  [<a href="#re:mario" name="CITEre:mario">6</a>]  They pointed out three major security flaws or vulnerabilities:
	
<ol type="1">
<li> an authentication failure
<div class="p"><!----></div>
</li>

<li> a key refreshment flaw
<div class="p"><!----></div>
</li>

<li> the unreliable support of the deniability
<div class="p"><!----></div>
</li>
</ol>
And all these three weaknesses are caused by the inappropriate choice of the key agreement protocal. Because of improperly chosen to use signed keys authentication protocol, the OTR suffers a possible man-in-the-middle attack. . On the other hand, if we attach the signatures to each message to solve this problem, it will remove the deniability property. Moreover, the reveal of an ephemeral private key will cause an impersonate attack. An attacker could easily replay the message, g<sup>x</sup>, Sign<sub>Alice</sub>(g<sup>x</sup>), and he/she can compute the session key upon whatever g<sup>y</sup>(i.e. Bob's pubic key) responsed from Bob, as long as the public key of Alice is not revoked. Therefore, they suggested to do a fully fresh periodically. Furthermore, the improper mechanism of revealing MAC keys weakens the secrecy of encryption keys. The attacker can use this knowledge to mount a dictionary attack, althrough it is probably expensive. Consecutively, they suggested three alternative AKE(Authentication Key Exchange) algorithms, SIGMA, SKEME and HMQV, and discussed both the advantage and disadvantage of using these three protocols.

<div class="p"><!----></div>
This discussion leads the OTR researchers reconcerned their design and affirmed the second version of the OTR protocol [<a href="#re:otr-protocol" name="CITEre:otr-protocol">13</a>], where:
	
<ol type="1">
<li> They fixed the identity-binding flaw (the impersonate attack vulnerability) simply by adding additional identification message at the beging of the conversation session.
<div class="p"><!----></div>
</li>

<li> No longer revealing the users' public keys to passive eavesdroppers and this helps in privacy-perserving for the internal application's OTR messages.
<div class="p"><!----></div>
</li>

<li> Supporting fragmentation OTR messages since a lot of Instant Messaging protocols have limitation on each message's size.
<div class="p"><!----></div>
</li>
</ol>

<div class="p"><!----></div>
----OOOOOO-------

<div class="p"><!----></div>
     <h3><a name="tth_sEc3.3">
3.3</a>&nbsp;&nbsp;Lack of Chat Room Support</h3>
Chatroom systems are also being utilized by businesses to increase the efficiency. A chat room system is more suitable for online discusions than conventional mailing-list systems due to its interactive nature. Many small businesses use chat room systems (and/or IM systems) for daily business discussions, customer service, etc. Using such technologies cuts on the operation cost of a business as well and enables employees multiplex between tasks when necessary. Many open source projects use chat room systems to conduct development meetings, since most open source projects are developed by programmers located in disparate locations.  There is, however, no privacy protection in most current chat room systems. Security concerns associated with chat rooms limit their use for many businesses.  

<div class="p"><!----></div>
Some IM systems have chat room support built into them. For example, MSN and Yahoo IM protocols support chat room concept and once a user invites another user to an ad-hoc chatroom, they can invite other parties to have a meeting in that established chatroom. Considering security related issues (associated with both IM systems and chat rooms) mentioned previously, it would be beneficial to address the OTR protocol to support secure chatroom facilty. 

<div class="p"><!----></div>
A secure chat room that utilizes the existing IM infrastructure would bear virtually no cost on the participants. An IM-based secure chatroom will also avoid the need for a VPN or dedicating a local server and the challenges that come together with having such systems and their management. Hence, we extended the OTR protocol with a schema to support multi-party conversations and implemented a GAIM plugin. Our implementation currently supports secure chat room support for the MSN IM protocol. 

<div class="p"><!----></div>
 <h2><a name="tth_sEc4">
4</a>&nbsp;&nbsp;Methodology and Implementation</h2><a name="se:methodology">
</a>

     <h3><a name="tth_sEc4.1">
4.1</a>&nbsp;&nbsp;Initial thought</h3>
The main concept of our implementation is to make a virtual server. What we mean by the term virtual server is that one of the participants acting as a server for the chatroom. The server, which can be any one of the participants in the conversation session, will do key exchanges with every other participant the same way as if he/she would for a regular peer-to-peer OTR conversation. Therefore, the virtual server is sharing a secrect with each chat room member. In other words, every one except the server itself will establish a private channel with the host, each having its own secret with the host. The virtual server is responsible for routing and broadcasting all IMs, which means the virtual server needs to transfer all the messages from one chat room member to every one else, as seen in Figure <a href="#fig:schema2">1</a>.

<div class="p"><!----></div>
For example, in the chat room, we have three chat members Alice, Bob and Carol, and suppose that Alice is the the virtual server. So after all the the key exchange processes conclude, we should have:

<ul>
<li> Bob and Alice have a shared secret SS<sub>Alice<font face="symbol">-</font
>Bob</sub>.
<div class="p"><!----></div>
</li>

<li> Carol and Alice have a shared secret SS<sub>Alice<font face="symbol">-</font
>Carol</sub>.
<div class="p"><!----></div>
</li>
</ul>

<div class="p"><!----></div>

<div class="p"><!----></div>
<a name="tth_fIg1">
</a> <center><a href="schema2.eps">Figure</a>

<center>Figure 1: Schema 2: Make a virtual server in the middle</center>
<a name="fig:schema2">
</a>
</center>
<div class="p"><!----></div>
<b>Problem:</b> <i>How can Bob communicate with Carol?</i> <br />
Bob does not send his OTR IMs directly Carol since they two do not have a common secret and if he did, Carol would not be able to decrypt his messages. However, they can start their own OTR session and talk to one another without Alice knowing (Alice would not be able to see their messages). Both Bob and Carol have a shared secret with the Virtual Server, Alice, therefore Bob can send OTR IMs to Alice. Alice is responsible for decrypting Bob's IM by using SS<sub>Alice<font face="symbol">-</font
>Bob</sub> and re-encrypt it SS<sub>Alice<font face="symbol">-</font
>Carol</sub> and send to Carol. Our implementation is based on this idea.

<div class="p"><!----></div>
     <h3><a name="tth_sEc4.2">
4.2</a>&nbsp;&nbsp;Detail Design</h3>
The MSN Messenger [<a href="#re:msn" name="CITEre:msn">1</a>], developed by Microsoft, has been around July, 1999. It became popular along with the wide use of Windows systems. The end users' MSN applications are called "MSN Client"; it connects to the "MSN Server" hosted by Microsoft to acquire information about the user's personal profile, buddy list and so on. Whenever a user modifies her profile, the client sends this information to the server and the server notifies other users in your buddy list.

<div class="p"><!----></div>
MSN protocol has built in support for chat rooms. There are no major differences between a two-party conversation session (referred to as 'SwitchBoard') and a chat room session other than the number of users in the session. If one user wants to invite another one to the chat room, she will query the <i> (NAME SERVER?????????????) NS <font size="-2">SERVER</font></i> by sending an invite command and the invited user will receive an RNG command  <i>(<font size="-2">RING</font>)</i> containing the session id, buddy list of the chat room, etc. Notice that, all messages exchanged in the chat room session are broadcasted to every user along with sender's account name, the message body and <b><i>probably</i></b>  PLEASE VERIFY THIS the timestamp. <br />

<div class="p"><!----></div>
<b>Design Problem 1:</b> <br />
The MSN IM protocol specifices that messages sent out in a chat room are broadcasted to every user in that session automatically. Therefore, in our design, it is hard to tell the real receiver of the message (the virtual server). In our virtual server scenario, a user only has the capability to decrypt the IMs coming from the virtual server and all messages come from other users are meaningless to him (a user in that session has a common secret only with the virtual server). Hence, we need an identifier at the beginning of a message to identify the receiver of the message. If the user receives an IM that is not for her, she could simply discard it, since this message is not encrypted with her key and she would not be able to read it.

<div class="p"><!----></div>
We will state some examples to show working of our implementation. Assume we have an OTR chat room via MSN IM with three users: OTR1, OTR2, and OTR3. OTR1 is the virtual server for this secure chat session:

<div class="p"><!----></div>
<b>Example 1:</b> <a name="ex:example1">
</a><br />
OTR1, the virtual server, sends a message (No matter what kind of message. It can be an OTR query message which used to ask for key exchange or a normal encrypted message) to OTR2, the message will be formatted to the following style: 

<center>

<pre>
OTR1-&#62;OTR2:
?RECV?OTR2@hotmail.com?ENDRECV?
&nbsp;+&nbsp;&lt;Encrypted&nbsp;Message&#62;

</pre>
</center>
When OTR3 receive this message he will check the tag first, if it is not his according to the account name in between 'RECV' and '?ENDRECV?' tags, he will just discard the message. And when OTR2 receives this message, after he checks the tag and finds out the IM is for him, he will send this IM to OTR message routine (using OTR library) to use the shared secret key between him and OTR1 to decrypt this message and write to the screen. 

<div class="p"><!----></div>
<b>Example 2:</b> <br />
OTR2 wants to send an IM to OTR3 in the chat room. In order to do this, OTR2 has to send his IM first to OTR1, the virtual server. OTR2 won't send out this IM message with receiver set to [OTR3@hotmail.com], because OTR3 he can not decrypt it without shared secret between them. <br />
The message will be:

<center>

<pre>
?RECV?OTR1@hotmail.com?ENDRECV?
&nbsp;+&nbsp;&lt;Encrypted&nbsp;Message&nbsp;from&nbsp;OTR2&#62;

</pre>
</center>
When OTR1 received it, he will decrypt it with the SS1, write the message to his screen and then encrypt it again with SS2 and format the IM will be:

<center>

<pre>
?RECV?OTR3@hotmail.com?ENDRECV?
&nbsp;+&nbsp;&lt;Encrypted&nbsp;Message&nbsp;from&nbsp;OTR1&#62;

</pre>
</center>
Now, for the reason that OTR3 and the server have a shared secret (a secure channel), OTR3 can read and decrypt this message without problem. But this brings us to another issue.<br />

<div class="p"><!----></div>
<b>Design Problem 2:</b><br />
Since the server is basically a router and responsible for reformatting and transfering all the messages, it is really impossible to know the real sender without an additional setting. There is no  support for "message tracking" or "traonsitive authentication" in either the MSN protocol and or GAIM project. The solution we propose is to add another tag after the receiver tag to indicate the real sender. Therefore the messages will have the following format;

<div class="p"><!----></div>
In accordance with example 1:

<div class="p"><!----></div>

<pre>
OTR1-&#62;OTR2:

?RECV?OTR2@hotmail.com?ENDRECV?&nbsp;
+&nbsp;?SEND?OTR1@hotmail.com?ENDSEND?
+&nbsp;&lt;Encrypted&nbsp;Message&#62;

</pre>

<div class="p"><!----></div>
For the second example:

<div class="p"><!----></div>

<pre>
First&nbsp;OTR2-&#62;OTR1:

?RECV?OTR1@hotmail.com?ENDRECV?
+&nbsp;?SEND?OTR2@hotmail.com?ENDSEND?
+&nbsp;&lt;Encrypted&nbsp;Message&nbsp;with&nbsp;SS1&#62;

And&nbsp;then&nbsp;OTR1-&#62;OTR3:

?RECV?OTR3@hotmail.com?ENDRECV?
&nbsp;+&nbsp;?SEND?OTR2@hotmail.com?ENDSEND?
&nbsp;+&nbsp;&lt;Encrypted&nbsp;Message&nbsp;with&nbsp;SS2&#62;


</pre>
At this point, all the IMs include the necessary tags to identify who the real sender and the receiver are. <br />

<div class="p"><!----></div>
<b>Design Problem 3:</b><br />
This problem rose because of a "weakness" in MSN IM protocol.
In MSN IM protocol, every one in a chat room has the same privilege, which means there is no identifier for who is the "owner" of the chat room established via MSN IM server. Every one in the chat room can invite another buddy without any permission. Since we would like to offer participants a degreee of security via OTR, we worked around this problem in the following way: Some additional information about the chat room is written in a file named <i>otr.chatinfo</i> located in .gaim folder, which is used by GAIM. The file has the following format:

<center>

<pre>
?AC?[account&nbsp;name]	?CID?[chat_id]	?HOST?[host&nbsp;name]		?STAT?[security&nbsp;level]

</pre>
</center>
<b>AC</b>: indicate the account name of the user who owns the current conversation window. <br />
<b>CID</b>: <tt>chat_id</tt> is used by GAIM to identify different chat rooms. <br />
<b>HOST</b>: the user who made to be the virtual server for the MSN chat session. <br />
<b>STAT</b>: indicate the security level used by OTR library; the security level can be:

<ul>
<li> 0 indicates no private conversation.
<div class="p"><!----></div>
</li>

<li> 1 indicates private session over.
<div class="p"><!----></div>
</li>

<li> 2 indicates private session.
<div class="p"><!----></div>
</li>
</ul>
Implementation Assumptions: <br />
The user who begins the conversation session, (the guy who clicks the OTR button and sends out the OTR query to start the private OTR session) would be the server. For example: timootr2@hotmail.com wants to start a private conversation, so his <i>otr.chatinfo</i> will be:

<center>

<pre>
?AC?timootr2@hotmail.com	?CID?1	?HOST?timootr2@hotmail.com	?STAT?2

</pre>
</center>
For a chat member instead of the virtual server, like timootr1@hotmail.com, when he receives the first OTR query message from the timootr2, the virtual server, he will write the following information to his <i>otr.chatinfo</i> file:

<center>

<pre>
?AC?timootr1@hotmail.com	?CID?2	?HOST?timootr2@hotmail.com	?STAT?0

</pre>
</center>
Here, his security status is 0, not private.
And after they finish the first key exchange round and establish a private communication channel, his security status will be changed to 2, private level:

<center>

<pre>
?AC?timootr1@hotmail.com	?CID?2	?HOST?timootr2@hotmail.com	?STAT?2

</pre>
</center>

<div class="p"><!----></div>
 <i><b>HOW ABOUT USER 3? AND HOW DO WE STOP SAY USER 2 WHO IS <font size="-2">NOT</font> <font size="-2">THE</font> <font size="-2">SERVER</font> <font size="-2">FROM</font> <font size="-2">INVITING</font> <font size="-2">ANOTHER</font> <font size="-2">USER</font>, <font size="-2">SAY</font> <font size="-2">USER</font> 4?</b></i> 

<div class="p"><!----></div>
 <h2><a name="tth_sEc5">
5</a>&nbsp;&nbsp;Conclusion and Future Work</h2><a name="se:conclusion">
</a>
There is need for secure chat room environment via the existing IM infrastructure and an approach to extending OTR to provie secure chat room support via IM is provided. The proposed approach is useful in adressing needs of individuals (e.g. small businesses where confidentiality of information is crucial) to have off the record and secure meetings with virtually no cost. A proof of concept plugin for GAIM is developed. Although the current implementation currently supports chat rooms via MSN IM network, the proposed idea can be extended to support other IM protocols such as Yahoo IM, AOL IM, etc. 

<div class="p"><!----></div>
While we realize the additional network traffic introduced by our approach (e.g. the discarded IMs), IM messages tend to have small payloads and we chose to accept slight loss of performance (un-noticable for four users in a chat room) than to deal with the complicated issue of group key-exchanging protocols particularly in Deffie-Hellman key agreement. Performance of key management algorithm remains to be a performance issue to consider. We believe that causing and discarding the additional traffic which is light and in which packets have small payloads, will not hinder the performance as a complex group key management protocol would. We are currently working on this problem and find a way for efficient key management so we can avoid the excess traffic our approach generates. 

<div class="p"><!----></div>
There is an additional security issue remaining to be solved in our schema. There is always a possibility that the virtual server gets attacked. The virtual server has the ability to read the IMs and it is responsible for delivering them. Hence, if the virtual server turns into a bad guy, it could read IMs from one user, modify them and transfer to the other users. We think the integrity of the IMs can be assured by maintaining MD5 (any one-way hash table should be applicable) values of the original messages on each user's computer and verifying them periodically. In order for this approach to work, the chat room participants must be able to transfer the hash signatures of their IMs out-of-band (without going through the virtual server). This approach will cause further traffic. Currently, users can establis out of band (direct MSN IM) secure OTR sessions and verify if they suspect the virtual server is altering messages. However, an automated way of checking IMs' integrity would be beneficial. We believe this issue can be resolved when a proper solution for group key managemment protocol is implemented. 

<div class="p"><!----></div>


<div class="p"><!----></div>
<h2>References</h2>

<dl compact="compact">
 <dt><a href="#CITEre:msn" name="re:msn">[1]</a></dt><dd>
2 plus
43 minus
  4
(2006) Windows live messenger. Microsoft Corp. [Online]. Available:
  http://get.live.com/messenger/features


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:aim" name="re:aim">[2]</a></dt><dd>
2 plus
43 minus
  4
(2006) American online, aim. American Online. [Online]. Available:
  http://aimexpress.aol.com/


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:irc" name="re:irc">[3]</a></dt><dd>
2 plus
43 minus
  4
(2006) The irc prelude. © IRCHELP.ORG. [Online]. Available:
  http://www.irchelp.org/irchelp/new2irc.html


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:diffie-hellman" name="re:diffie-hellman">[4]</a></dt><dd>
2 plus
43 minus
  4
(1999) Rfc2631:diffie-hellman key agreement method. The Internet Society -
  Network Working Group. [Online]. Available:
  http://www.ietf.org/rfc/rfc2631.txt


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:borisov:04" name="re:borisov:04">[5]</a></dt><dd>
N.&nbsp;Borisov, I.&nbsp;Goldberg, and E.&nbsp;Brewer, "Off-the-record communication, or, why
  not to use pgp," in <em>WPES '04: Proceedings of the 2004 ACM workshop on
  Privacy in the electronic society</em>.&nbsp;&nbsp;&nbsp;
  New York, NY, USA: ACM Press, 2004, pp. 77-84.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:mario" name="re:mario">[6]</a></dt><dd>
M.&nbsp;D. Raimondo, R.&nbsp;Gennaro, and H.&nbsp;Krawczyk, "Secure off-the-record
  messaging," in <em>WPES '05: Proceedings of the 2005 ACM workshop on
  Privacy in the electronic society</em>.&nbsp;&nbsp;&nbsp;
  New York, NY, USA: ACM Press, 2005, pp. 81-89.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:iso-security" name="re:iso-security">[7]</a></dt><dd>
<em>Information Processing Systems - Open Systems Interconnection Reference
  Model - Security Architecture</em>, International Organization for
  Standardization Std. 7498-2, 1988.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:simpro" name="re:simpro">[8]</a></dt><dd>
2 plus
43 minus
  4
(2006) Simppro: Instant messengers, instant security. Secway. [Online].
  Available: http://www.secway.fr/us/products/simppro/


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:google-talk" name="re:google-talk">[9]</a></dt><dd>
2 plus
43 minus
  4
(2006) Chat history saving. ©Google. [Online]. Available:
  http://www.google.com/talk/chathistory.html


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:rc5" name="re:rc5">[10]</a></dt><dd>
R.&nbsp;L. Rivest, "The rc5 encryption algorithm," in <em>In the Proceedings of
  the Second International Workshop on Fast Software Encryption</em>.&nbsp;&nbsp;&nbsp; FSE, 1994, p. 86–96.

<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:gaim-e" name="re:gaim-e">[11]</a></dt><dd>
2 plus
43 minus
  4
(2002) Gaim-e, encryption plug-in for gaim. Gaim-e Project. [Online].
  Available: http://gaim-e.sourceforge.net/


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:jablon96strong" name="re:jablon96strong">[12]</a></dt><dd>
2 plus
43 minus
  4
D.&nbsp;P. Jablon, "Strong password-only authenticated key exchange,"
  <em>Computer Communication Review</em>, vol.&nbsp;26, no.&nbsp;5, pp. 5-26, 1996.
  [Online]. Available: citeseer.ist.psu.edu/jablon96strong.html


<div class="p"><!----></div>
</dd>
 <dt><a href="#CITEre:otr-protocol" name="re:otr-protocol">[13]</a></dt><dd>
2 plus
43 minus
  4
(2005) Off-the-record messaging protocol version 2. Off-the-Record Messaging
  Project. [Online]. Available:
  http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html


<div class="p"><!----></div>
</dd>
</dl>
<br /><br /><hr /><small>File translated from
T<sub><font size="-1">E</font></sub>X
by <a href="http://hutchinson.belmont.ma.us/tth/">
T<sub><font size="-1">T</font></sub>H</a>,
version 3.67.<br />On  1 Feb 2007, 13:41.</small>
</html>
